透過 WebRTC 實現一對一的連線，那麼也能完成多人通話嗎？這篇就來討論 WebRTC 能否實現多人視訊通話、會遇到什麼問題、有沒有其他方法。

一對多直播

若照先前的方式 host 需要為每個新加入的 guest 建立 peerConnection 發送 SDP，但在一對多時更好的方式是由 guest 發送 offer 、host 回覆 answer ，host 只需要不斷監聽新的 SDP 並且回覆即可，因為 guest 是動態的加入。

但在這個情況下，不斷發送 answer 的 host 會建立多個 peerConnection ，對於大規模直播，STUN（Session Traversal Utilities for NAT）伺服器會產生較大的壓力，因為每次回應都需要使用 STUN 伺服器來處理 NAT 遍歷和 ICE 協議。

備註：addTransceiver（） 可以實現單向接收串流，指設備沒有鏡頭及麥克風，只是想觀看對方的視訊時可以使用

多人視訊通話

每個參與者在加入房間後，都需要建立一個 peerConnection ，當一個新的 guest 加入房間後，建立一個 peerConnection 並發送一個 offer 到 server，server 收到 offer 後，確定要將 offer 轉發給哪些其他參與者，並回覆 **answer，**當參與者加入房間後，他們之間需要建立連接。這可以通過主持人轉發參與者的 SDP 來實現，或者也可以直接通過 DataChannel 進行通信。

這是一個更複雜的情況，因為每個參與者都可以連接到其他多個參與者，同樣產生多個 peerConnection 也帶給 server 很大的負擔。

更好的解決方式

圖片來源：webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU - 菩提树下的杨过 - 博客园 (cnblogs.com)

在之前的範例中我們都是使用 Mesh 架構進行點對點連接，一般這種架構只能支援4-6人左右，不過優點也很明顯，沒有中心節點，實作簡易，但在上述一對多、多對多的複雜情境下較適合用MCU、SFU的兩種伺服器架構。

1. SFU（Selective Forwarding Unit）不混合或合併媒體流。接收來自多個參與者的媒體流，將這些 MediaStream 轉發給其他參與者。
2. **MCU（Multipoint Control Unit）**接收來自多個參與者的媒體流，收集所有參與者的視訊和音訊流混合或合併 MediaStream 並將其傳送回參與者，常用於視訊會議，其中需要共享視訊和音訊。
3. 即時通訊平台API： 許多即時通訊平台（如Twilio、Agora、Zoom等）提供API，可以簡化多人視訊通話的實現，並提供更強大的功能。

總結

由於 WebRTC P2P 連線的限制，在實現多人通話時，可考慮使用 SFU 或 MCU 方式來解決伺服器連接和性能問題。

參考資料

【從頭到腳】前端實現多人視訊聊天— WebRTC 實戰（多人篇）| 掘金技術徵文 | IT人 (iter01.com)
Day29 使用 addTransceiver 單向接收串流 - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天 (ithome.com.tw)
WebRTC 之 addTransceiver() 与 addTrack（） - 掘金 (juejin.cn)
RTCPeerConnection： addTransceiver（） 方法 - Web API |多核 (mozilla.org)